Trust is a crucial aspect in e-commerce, communications, and related applications. Since e-commerce is implemented using both mobile and land based computing platforms, enhancing trust in these computing platforms is a fundamental issue and is of growing importance in the computing industry.
The Trusted Computing Platform Alliance (TCPA) formed in 1999 by Intel, HP/Compaq, IBM, Microsoft, and other companies, proposes a new computing platform for this century that will initially provide improved trust in the Personal Computer (PC) platform with eventual trust provided by the Trusted Mobile Computing Platform (TMCP). The TCPA promotes the concept of a trusted subsystem and chains of trust between such subsystems, so as to provide the basic building blocks for e-Commerce.
Originating from the TCPA, the Trusted Computing Group (TCG) focuses on open standards to enhance the overall security and trustworthiness of a variety of computing devices. One such standard is the Trusted Mobile Computing Platform (TMCP) that includes standards for trusted computing using mobile terminals. Ongoing efforts by the TCG continue to focus on the impact of TCPA on mobile commerce because the TCPA was initially intended for land based computing systems such as the PC.
The Trusted Platform (TP), as defined by the TCPA, is a platform that behaves the way it is expected to behave for its intended purpose. The TCPA definition of a trusted system is a system that always behaves in the expected manner for the intended purpose. The trust of a TCPA computing platform is built upon a root trust, which is convinced by sound existing technologies, including both hardware and software technologies. The root trust is realized through the TCPA subsystem, which typically consists of a root of trust for measuring integrity metrics; a Trusted Platform Module (TPM); and other Trusted Support Systems (TSS). The TCPA subsystem supports two roots of trust: the root of trust for measuring integrity metrics and the root of trust for storing and reporting integrity metrics, which is realized by the TPM.
The way in which a remote computing platform can be trusted is as follows. First, integrity metrics are queried from the platform, which are digitally signed by the trusted component of that platform. Second, the integrity metrics are compared with expected values that represent components that are trusted enough to perform the intended purpose. Third, if the compared values match the expected values, trusted interaction with the remote computing platform may be commenced. Anomalous metrics indicate that the platform is not operating as expected and further correspondence with the platform should be considered very carefully.
The TCPA strives to provide authenticity, integrity, and privacy so that: 1.) users are confident that they know to whom and to what entity they are communicating; 2.) transfer of information occurs accurately; and 3.) potential snoopers cannot invade the privacy of the system, message, or transaction. Trust, however, has several complicated and multi-dimensional concepts associated with it. Trust, for example, is dynamic because the level of trust that is considered sufficient varies for each individual and it varies over time. Trust is affected by many factors that are both subjective and objective, making a correct evaluation of trust difficult indeed.
Additionally, trust is not always transitive, meaning that: if entity A trusts entity B; and entity B trusts entity C; trust between entity A and C is not always conferred, although it may be in certain situations. Trust has varying degrees and scope, where entities typically develop trust for each other for their intended purpose, but that trust is not always transferred to other interactions between the entities.
Since trust is dynamic, it is impossible to provide a static/absolute trust solution. Accordingly, one disadvantage of the current TCPA paradigm, is that it does not provide a dynamic solution and is thus unable to tailor its protection for the changeable trust component. The static nature of the current TCPA solution, therefore, may cause a waste of resources and unnecessary attestation when the trust level is actually very high, while failing to satisfy security requirements for transactions when the trust level is actually very low.
Through checking of the integrity metrics, the root trust may trust the Basic Input Output System (BIOS), the BIOS may trust the Operating System (OS), the OS may trust the software application, and the software application may trust other remote systems. The chain of trust, however, does not necessarily remain intact for an extended length of time, nor does it remain in tact after hardware or software configuration changes. Accordingly, the trust chain is built up during system boot, which means that the OS can only verify its trust for previously identified configurations, thus failing to verify trust for any newly added hardware or software components.
Generally speaking, the TCPA fails to provide a model whereby integrity metrics may be trusted remotely. In particular, software applications may be able to record the challenge requests and their corresponding correct integrity metrics and thus may be able to replay the integrity metrics during subsequent integrity metrics requests. Once the recordings are complete, Denial of Service (DoS) attacks may also be implemented whereby TCPA compliant systems may be inundated with challenge requests and effectively crippled due to the sheer quantity of processing required by the challenge requests. One possible solution for these attacks is to time stamp the integrity metrics, however, a remote challenge procedure is easily simulated whereby signed integrity metrics may be obtained with a valid time stamp and subsequently replayed. Other solutions involve using serial numbers to identify the signed integrity metrics, the use of short-life cycle certificates or frequent polled metric checks, but each method is either non-economic, non-feasible, or provides limited attack protection.
Another area of deficiency within the trusted computing environment is exhibited by Java-2 Platform Micro Edition (J2ME) applications. Although certain security provisions are provided by the security and trust services Application Programming Interface (API) for J2ME, i.e., Java Specification Request (JSR) 177, it fails in many respects to provide adequately trusted operations.
In order to perform trusted operations, J2ME applications need to rely on the security services provided in a security element to ensure that, for example, the cryptographic keys are stored securely and that the cryptographic computations are performed securely. The proposed JSR 177 APIs establish a Java programming model for accessing the features of a security element, however, the trusted operation issue cannot be solved by JSR 177 because it simply focuses on MIDlet interaction with the security element, such as a smart card. The JSR 177 defines a collection of APIs that provide security services to J2ME enabled devices, i.e., it provides an access model that enables applications running on J2ME enabled devices to communicate with a smart card inserted in the device, but it fails to consider that the mobile code may be modified from its original state and may no longer be trusted. Digital signatures and Digital Rights Management (DRM) procedures are currently unable to solve the problem.
Accordingly, there is a need in the computing/communications industry for a system and method that implements trust based on the current TCPA/TCG technology while improving upon its propensity to counteract spoofing attacks and its ability to maintain trust.
Additionally, there is a need to provide a self-regulating mechanism that maintains trust without the need for unnecessary communication and computation.